[レポート]オブザーバビリティのためのSnowflake Trail

2024年9月11日～2024年9月12日に、「SNOWFLAKE WORLD TOUR TOKYO」が開催されました。

https://www.snowflake.com/events/snowflake-world-tour-tokyo/

本記事はセッション「オブザーバビリティのためのSnowflake Trail」のレポートブログとなります。

登壇者

• Snowflake合同会社 セールスエンジニアリング統括本部 アソシエイトパートナーセールスエンジニア 宮川 大司 氏

セッション内容

• アプリケーション・データパイプライン構築時の主な課題
  • セットアップ自体が煩雑で時間がかかる
  • トラブルの原因究明が困難
    • ストアドプロシージャ・UDF のトラブルシューティング
• オブザーバビリティが必要

• Snowflake Trail
  • 上記の課題に対するソリューション
  • Snowflake でのパイプラインやアプリケーションのトレース・トラブルシューティング、デバッグ、対応策の実行を簡単かつ効率的に行えるために Snowflake に組み込まれた一連のオブザーバビリティ機能群
  • コードによるウェアハウスのリソース消費状況や実行速度にどの程度影響を与えるかを可視化する機能も含まれる

• Snowflake Trail の特徴
  • 使いやすさを重視して設計されている
    • テレメトリの収集は設定変更のみで可能
    • 平均検出・修復時間を短縮するような設計
  • データの移動も不要
  • Snowflake の機能以外にパートナーツールとの連携も可能
    • 業界標準の OpenTelemetry に基づいて構築されているため

• Snowflake Trail の概要
  • 昨年、イベントテーブルをリリース
    • Snowpark のコードや UDF、ストアド プロシージャからログ情報をキャプチャできる特別なタイプの Snowflake テーブル
  • 既存の Alert や通知機能と統合されて単一のテレメトリ基盤として提供できるようになってきている

• 今後は Snowpark コンテナサービスなどにも拡大予定

• Snowpark のオブザーバービリティ
  • 以下のような項目を収集できる

• デモ
  • 設定：データを UDF やストアドプロシージャで変換して LLM・Streamlit で可視化する例
  • 赤枠部分がどのように見えるかをデモ

• まずはテレメトリを有効化する
  • 設定変更はこれだけでよい
    • デバッグやトラブルシューティングできるようにログレベルを設定
      • ログレベルは ERROR を推奨
    • トレースレベルを ALWAYS とすることですべてのアクションイベントを記録でき、デバッグが容易になる
  • Snowpark 用のメトリクス収集もプライベートプレビュー

• OSS の OpenTelemetry の仕様に準拠するため、Snowpark のストアドプロシージャや UDF が実行されるとイベントテーブルにスパンとして記録される
  • スパン：特定のイベント実行時間
• すべてのスパンがキャプチャされ、トレースやスパン間の関係が分散トレーシング図として表せる

• どのように機能するか
  • 各スパンIDはイベントテーブルに記録される
    • 共通のトレースIDで関連付けられる
  • 例：ストアドプロシージャで UDF を呼び出すと、それぞれのスパンIDは前のスパンIDを親スパンIDとして引継ぐ
    • ストアドプロシージャ内で別のストアドプロシージャを呼び出す場合でもこのプロセスが適用される

• 実際の画面
  • [モニタリング] > [トレースとログ] からとトレースを選択すると下図のように分散トレーシング図が表示される
  • 下図ではストアドプロシージャ内で UDF が呼び出されている様子がわかる
  • 黄色の箇所：XS のウェアハウスを使用しているので、8つのスレッドを使用して Python スクリプトやクエリの処理を実行している様子が見える
    • ウェアハウスサイズ変更するとこの様子も変わる

• エラー発生時にどのように見えるか
  • これまではクエリの詳細からエラーメッセージを確認するしかなく、解析に時間がかかる場合があった
  • 追加機能のクエリテレメトリーよりスパン毎に図のように確認できるようになる

• 設定によって特定のロジックがどの程度時間がかかったか、またメモリや CPU の消費量も確認できる

• 機能まとめ

• すでに利用可能なアラートや通知機能との連携によるエラー通知も可能

• User Code Profiler for Snowpark
  • ストアドプロシージャや UDF のプログラムコードのどの部分で最もリソースがかかっているか調査できる機能
  • セッションパラメータを有効化することで利用できる
  • ※現在プライベートプレビュー

• Snowpark コンテナサービスのログキャプチャ
  • 今後は Snowsight からも利用できるように

• データパイプラインのオブザーバビリティを向上させる機能
  • タスクグラフ
    • 特定のタスクのフィルタ
    • エラーメッセージの確認
  • ダイナミックテーブル
    • 最新の更新状況の把握
    • グラフビューによる依存関係の可視化
  • コピー履歴

• データ品質も組み込み機能で監視可能
  • Data Quality and data metric functions

• OpenTelemetry 準拠なので他ツールと連携可能

• 事例

さいごに

Snowflake Trail についてデモを交えつつご紹介いただいたセッションでした。分散トレーシング図の表示など一部パブリックプレビューやプライベートプレビュー段階のものがありますが、特にデータパイプラインにおいて Snowpark による変換処理を記述している場合にそのエラー調査を容易にできる機能とのことです。既存の機能とそのまま連携できるので、通知機能の実装も容易です。Snowpark を本格利用している組織では待ち望まれている機能ではないでしょうか。